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(57) Abstract 



An authentication 
server is provided which 
stores authentication details 
of authorised users, and a 
list of cunently-eudicnticated 
A number of application 
are connected to the 
autfaentfcation server, to aUow 
die applkation serven to check 
die cunent authmricalion status 
of a user which requests service 
by the appUcation serven. 
A session key is gM»^«iffd 
during die audieatication 
procedure, for use during 
subsequent communkadons. 
One embodiment of applicadon 
server which is adapted for 
use in combinadon with tiie 
audiendcadon server is a file 
transfer server which allows 
audienticaiBd users to upload 
files using a fiist session icey 
generated during audienlication 
of die. sending user, and which 
allows a recipient to retrieve 
the file in encrypted fonn using 
a second session key which is 




generated during die audiendcadon of die second user. The file transfer server also allows a file sender to specify a release date for data 
transmitted to die server. In one embodiment, die transmitted file is doubly encrypted using not only die session key of die recipient, but 
also an enoypdon key which is released to die lecipient only after die specified dale and Umc. In anodier embodhnent, die file is stored 
on die server undl such dme as the specified dale and dme have passed, before being released to die reciptent 
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DATA COMMUNICATIONS 

This invention relates to data communications, and in particular, but 
not exclusively, to the communicatiDn of data via a public data 
communications network such as the Internet. 

S . Due to the inherently insecure nature of data communications via the 

Internet, and due to the sensitive nature of some information which is 
transmitted, various proposals have been made for the encryption of data for 
transmission. Thus, although third parties may be able to intercept messages, 
third parties will only be able to read the data within the message if they are 

10 able to decrypt the message using an appropriate encryption key. 

In public-key cryptography, such as that used in the RS A cryptography 
system, each person who is to receive encrypted data has a public key which 
is made available to anyone wishing to send that person data, and. a private key 
which remains confidential. Data encrypted with the public key can only be 

IS decrypted with dieir private key. This system suffers drawbacks in that, in 

order to send another party an encrypted message, the sending party must 
know the public key of the receiving party. Also, the authenticity of the 
sending party cannot readily be identified since the public key is, by definition, 
available to any other party. 

20 Another type of encryption system is secret-key cryptography^ also 

referred to as symmetric cryptography. In secret>key cryptography, the 
sending party and the receiving party share a common secret encryption key, 
which is used both to encrypt data before transmission, and to decrypt the data 
after reception. One drawback of this system is that the two parties must, 

25 before transnussion of the encrypted data, have agreed upon the shared secret 

key to be used. 

A further problem encountered in communications over the Internet is 
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that of the authentication of a user. When a user contacts' an Internet resource 
via the Internet, in many cases the resource will not be provided unless the 
third party has been authenticated. A common means of authenticating users 
is by requesting the input of a previously-established password by the user, 

S which is then checked by the resource to confirm the identity of the user. 

This password-based authentication procedure can be time-consuming to the 
user when the user wishes to have access to a number of resources. 

It would be desirable to provide improved methods, and means, for the 
transmission of data via the Internet, and for the authentication of Internet 

10 users. 

In accordance with one aspect of the invention there is provided a 
mediod of authenticating users for access via remote terminals, to a plurality 
of application servers, said method comprising the steps of: 

storing authentication details of authorised users; 
IS performing remote authentication of users with reference to said stored 

authentication details; 

storing data identifying users which are currentiy autiienticated; and 

allowing said plurality of application servers to access said data 
identifying currentiy authenticated users to check an authentication status of a 
20 user. 

This aspect of the invention provides for tht authentification of a user 
over the Internet using a single authentication fadtity, which maintains the 
authentication status of users in the system. When a user wishes to access any 
of the application servers they may each contact the central facility to confirm 
25 the authentication status of tiiat user, without needing to perform separate 

autiientication procedures directiy with the user. 

In accordance with a further aspect of the invention there is provided 
a method of transferring a file between a user at a first client termin^d and a 
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user at a second client ienriinal over the Internet, said method comprising the 
steps of: 

establishing a first session key by communicating with said first client 
terminal over the Internet; 
5 receiving the file encrypted with the first session key from the first 

client terminal over the Internet; 

decrypting the file using die first session key; 

establishing a second session key by communicating with said second 
client terminal over the Internet; 
10 encrypdng the file using the second session key; and 

transmitting the file encrypted with die second session key to the 
second client terminal. 

This aspect of the invention provides a file transferral method whereby 
a file may be securely transferred from a first user to a second user, without 
IS requiring the first or second users to perform any direct communications 

between their respective client terminals. Instead, the encryption system may 
be supervised by a "trusted diird party", which sepiarately generates session 
keys for communications with each of the first and second usen respectively. 

In accordance with a further aspect of the invention there is provided 
20 a method of transferring a file from a first client terminal to a second client 

terminal, said method comprising the steps of: 

holding file transfer parameters for a plurality of different file transfer 

types; 

transmitting data relating to at least one of said different file transfier 
25 types to said fint client terminal; 

receiving said file from said first client tenhinal; 
receiving data identifying a selected file transfer type from said first 
client terminal; and 
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transmitting said file to said second client terminal in accordance with 
die file transfer parameters stored for said selected transfer type. 

This aspect of the invention allows file transfers to be configured 
without requiring the file transfer parameten to be individually set up by the 
S user at the first client terminal. 

In accordance with a further aspect of die invention there is provided 
an application server for transferring data from a first client terminal to a 
second client terminal, said application server comprising means for receiving 
said data from said first client terminal, means for receiving a delay period 
10 indicator for said data from said first client terminal, and means for 

transmitting said data to said second client terminal such that said data can 
only be read by a user at said second client terminal after expiry of said delay 
period. 

This aspect of the invention provides a new data transmission service 
IS which may be implemented over die Inxemei. Rather dian waiting until a 

desired time to transmit the data to an application server, the first client 
terminal can specify the date and time for release of the data to die second 
client terminal when transferring die data to die application server, knowing 
diat the data will not be released until the specified date and time. 
20 Further features and advantages of the pre^t invention in its various 

aspects will be appreciated from die following description, referring to the 
accompanying drawings wherein: 

Figure 1 is a block diagram schematically illustrating a data 
transmission arrangement in accordance with the present invention; 
25 Figure 2 is a block diagram schematically illustrating the client/server 

communications between a client terminal and servers provided in accordance 
with die present invention; 

Figure 3 is a fiow diagram illustrating an authentication procedure; 
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Figure 4 is a bickrk diagnun schematically illustrating an authentication 
response^ and sesisibn key, generating algorithm; 

Figure S is a flow diagram illustrating procedures carried out by a 
server maintaining an updated list oif user authentication statuses; 
S Figure 6 is a flow diagram illustrating further updating procedures 

carried out by the server maintaining a list of currently authenticated users; 

Figure 7 is a flow diagram of authentication procedures carried out by 
an application server in accordance with a further embodiment of the 
invention; 

10 Figure 8 is a flow diagram illustrating an authentication status update 

procedure; 

Figure 9 is a block diagram schematically illustrating a flle transfer 
system in accordance with an embodiment of the invention; 

Figure 10 is a flo>y diagram illustrating procedures carried out by a file 
15 transfer server; 

Figures 11, 12, 13, IS and 16 are event sequences illustrating client/ 
server communications; 

Figure 14 is a block diagram illustrating a data transmission block in 
accordance with an embodiment of the invention; and 
20 Figure 17 is a block diagram illustrating a system for transferring e- 

mails in accordance with an embodiment of the invention* 

Figure 1 is a block diagram illustrating a data processing system in 
accordance with an embodiment of the present invention. The system consists 
of an authentication server (AS), consisting of a secure password server (SPS) 
25 and a cache management server (CMS), and a plurality of application servers 

(APSs). Three different classes of user terminals Tl, T2, T3 are connected 
to the system via a data communications network, in this embodiment the 
Internet. 
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The first is a terminal Tl having a unique IP address, and which can 
both open a TCP/IP connection and accept TCP/IP connection op^iing 
requests over the Internet. The second is a terminal T2 which has a unique 
IP address, which can open TCP/IP connections, but which cannot accept 

5 TCP/IP connection opening requests over the Internet, for example due to the 

presence of a fire wall 2 which the terminal T2 lies behind. The third is a 
terminal T3 which has no unique IP address* for example due to the use of a 
proxy server 4 through which the terminal T3 accesses the Internet. 
Communications over the Internet contain the IP address of the proxy server 

10 4, rather than that of the terminal T3. 

The application servers APS which are serviced by the audtentication 
server are remotely connected to the CMS via secure communications links 6 
(which may be separate physical links, or logical links which use secure 
encryption during communications), or are co-located with the authentication 

15 server. 

Eadi of the servers tUustrated in Figure 1 may be implemented on a 
computing resource, such as a work station computer. Each of the access 
terminals may be implemented in the form of a work station computer, a net 
computer, a mobile communications terminal, etc. 

20 Figure 2 is a block diagram illustrating the data communications which 

occur when a user wishes to access one of the application servers APS. The 
terminal contains software applications which indude an authentication client 
(AC) consisting of a secure password client (SPQ which communicates with 
the SPS over the Internet using TCT/IP, and a cache management server client 

25 (CMSC), which communications with the CMS over the Internet using 

TC7/IP. The terminal also includes at least one application client (APC) 
which communicates with the application servers APS using TCP/IP or 
UDP/IP. 
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The SPS has an associated data store 8 which holds authenticatiori 
details for each of the users authorised to have access to the application servers 
APS and a token identifying the access rights of each user. The CMS has an 
associated data store 10, which holds details of users currently logged on for 
S access to the application server APS, and which maintains logging on historiies 

for users once diey are logged off. 

Figure 2 illustrates the essential connections made when a user attempts 
to access one or more of the application servers APS. Communications 
between the SPC and SPS concern password-based authentication procedures. 
10 Communications between the CMSC and the CMS provide a mechanism for 

ensuring that a user remains logged on to the system when active, and for 
logging off a user when the user has become inactive. Communicationis 
between the APC and the APS provide the resources which the user wishes to 
access. The APS may be a WoridWide Web (WWW) server, in which case 
15 the application client is a WWW-enabled browser, such as Netscape Navigator 

(trade mark) and Microsoft Intnrhet Explorer, using the Hyper Text Transfer 
Protocol (HTTP) q)ecification to retrieve documents from the application 
server. Alternatively, the application server APS may be a server providing 
documents using the file transfer protocol (FTP), in which case the application 
20 client APC is an FTP-enabled client. However, the application servers APS 

may be any type of Internet resource server, and the terminals Tl, T2 are 
preferably provided with corresponding types of application clients such that 
a user may access any of the available application servers APS from that 
terminal. 

2S As will be discussed in greater detail below, the authentication 

procedure followed by the SPC and the SPS also provides a session key for 
use by the application client/application server combination during the coune 
of the session following log on. This will be explained in greater detail below. 
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Next, the authentication of a user at a terminal of the class Tl or T2, and 
subsequent access by the user to one or more of the application servers APS 
will be described. 

Figure 3 shows the log on procedure sequence followed by the SPS 

5 during logging on of a user from either of terminal Tl or T2. When a user 

at a terminal having a unique IP address wishes to access any of the 
application servers APS, they must complete a secure challenge-response log 
on process using the SPC. To initiate the log on process, the SPC opens a 
connection to the SPS» to which the SPS sends an acceptance greeting, stq) 20. 

10 This may be followed by a short query sequence during which die SPC sends 

a message to the SPS indicating the authentication protocol it intends to use, 
and the cryptographic code used by the SPC. If the SPS does not support the 
protocol or tiie code, die SPS will close the connection. 

The SPC initiates the log on process, by sending die log on request and 

IS the user name input by die user at the terminal, stq> 22. 

To authenticate the user, a challenge/response dialogue occurs b^ween 
die SPC and die SPS, step 24. The SPS generates a challenge which is sent 
to the SPC. The challenge consists of a random sequence of bytes generated 
by the SPC using a cryptographically secure random number generator, (i.e. 

20 one of which the output is extremely difficult to predict), which is sent as part 

of a "challenge" message to the SPC. 

At diis stage, bodi die SPC and die SPS perform die algorithm 
illustrated in Figure 4 which generates both a response to the challenge and a 
session key which may be used to encrypt and decrypt data sent to the terminal 

25 during the remainder of the session. The response and session key generation 

algorithm involves die hash functions HO, HI and H2. Each of diese is a one- 
way hash function, H(M), which operates on an arbitrary length message M 
and returns a fixed lengtii hash h (often referred to as a "fingerprint" or 
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"message digest" of message M). To guarantee security, the one-way hash 
functions have the following properties: 

1) given M, it is easy to compute h; 

2) given h, it is extremely difficult to compute or find M such that 
5 H(M) = h; and 

3) given M, it is extremely difficult to compute or find another 
message, M* such that H(M') - h. 

On the client side, the user name and password are input by the user 
into the terminal, and the SPC combines the two and performs the hash 

10 function HO to produce a fint hash. The first hash is combined with the 

challenge received by the SPC from the SPS and input to a second hash 
function HI to produce a second hash. The second hash is stored by the SPC 
for use as the session key to be used in secure communications during die 
remainder of the sessions. The second hash is also combined with the first 

IS hash and input into the third hash function, H2, to produce a third hash. The 

third hash is returned u> the SPS in a response message as the response to the 
challenge. 

The SPS database 8 contains, against each user name entry, the first 
hash produced by the operation of the hash function HO on the user name and 

20 password. The password is thus stored in hashed format, rather than in. 

plaintext, on the SPS database 8, to protect the password from parties who 
may have access to die database 8. On issuing the challenge, the SPS 
performs the algorithm shown in Figure 4, to produce the session key and to 
compute the response which is expected from the SPC. If die response 

25 received from die SPC matches that computed independently by die SPS die 

challenge/response procedure is successfully completed. However, if the 
correct response is not received, the SPS will allow the user a retry, step 26. 
Once a certain number of retries have failed (e.g. 3), the SPS sends the SPC 
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an error message, step 28, and closes the connection with the SPC, step 30. 

Notably, by use of the challenge/response sequence described, a session 
key, being a secret which is shared between the SPC and the SPS is generated 
without once sending the session key across die Internet. 
S In the next step of the log on procedure, the SPC sends a message to 

the SPS indicating the versions of die configuradon files of software installed, 
which describes the name and version number of die operating system Q30S» 
Windows, Macintosh, Acorn RISC OS etc), and die files which die SPC and 
CMSC contain. If die files are not up to date, die SPS transmits die latest 
10 versions to the SPC. These files may be encrypted widi die session key 

generated in step 24, which die SPC decrypts and stores. 

The session key generated during the challenge/response dialogue is an 
encryption key used in a symmetric block encryption algoridim, such as 
IDEA, or DES. The algoridim performs block by block encryption and 
IS decryption on die fly. In diis embodiment, the algoridim uses a 64-bit block 

cipher altiiough oihex block lengdis may be used for stronger or weaker 
encryption as desired. A checksum is added and encrypted, to allow checking 
of data to be performed on die SPC side and to allow die SPC to request 
retransmission of blocks in which an error has been found. The audientication 
20 details stored in the SPS database 8 may include an expiry date for the validity 

of the password used by the user during audientication. If so, and the 
password has expired, die SPS initiates a forced password change, step 34, 
using password change procedures to be described below before die log on 
details are passed on to the CMS. 
25 Once the user has been authenticated, the CMS receives a log on 

notification from die SPS. In addition to die authentication details, die SPS 
database 8 stores the session key generated during audientication and a token 
identifying die access rights against each user name, which are also passed on 
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to the CMS upon log on. 

As explained above, the CMS manages a cache 10 holding the details 
of all users which are currendy logged on to the system. The details passed 
from the SPS to the CMS in the log on notification include a unique identifier 
5 for the user, the hash (produced by HO) of the user name and password, the 

session key generated during authentication, die access rights token of the user 
and the current IP address of the user. 

The CMS checks die number of users concurrently logged on having 
the same user identifier. If diis exceeds a preset concurrency limit (for 
10 example once, to ensure that only one instance of a given user is logged on at 

any one time), and if the concurrency limit is exceeded, an rarpr message is 
sent to inform the user that they will not be logged on, st^ 28, and the 
connection is closed, step 30. Otherwise, the user is accepted as logged on by 
the CMS, and the SPC sends a "message of die day", st^ 36, and doses die 
IS connection, step 30. 

At this point, the user is fiilly logged on in a CMS, with die log on 
notification details stored in die CMS store 10. The us^ may dien, via an 
appropriate application client APC access one ore more of die application 
servers APS which die user is authorised to access, as specified by die access 
20 right token. 

When die ^plication client APC sends an access request to an 
application server, as shown in Figure 2, the request contains the unique IP 
address of die user terminal, Tl or T2. The application server APS dien 
sends a log on check to the CMS, via the secure link 6, including die IP 
2S address of the user. 

The CMS checks whedter diat IP address is present in die stored list 
of currendy logged on users. If so, it checks the access rights token stored 
against the same user, and if die user at diat IP address is bodi cdrrenUy 
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logged on and has access rights to the application server in question, the CMS 
returns an access allowed message to the application server. Otherwise, the 
application server APS receives an access denied message from the CMS and, 
if the application client has requested a connection, the application server 
5 refuses the connection, or if the application client AC has requested a 

document to be sent, the application server does not send the requested 
document 

Once a user is logged on to the system via the SPS, the CMS performs 
a pmodic check that the user remains logged on, using a challmge/response 

10 procedure similar to that used during the initial authentication of the nset. The 
procedure used by the CMS will depend on the type of terminal at which the 
user is logged on, in particiilar whether the CMS is able to contact the 
terminal to open a connection with it over the Internet (which is not possible 
for terminals of the class T2). 

IS Once a user is logged on to the system via the SPC, the usgc may 

initiate a password change, or a log off request using the SPC. If the user 
wishes to log off, the SPC sends a log off request to the SPS, step 38, to 
which the SPS responds by sending a log off notification to the CMS, which 
will then remove the user from the list of logged on users. The CMS also 

20 updates the log on history for the user, storing the log on time, for billing 

purposes. 

If the user wishes to change their password, or the user is forced to 
change their password, the SPC prompts the user to enter a new password, 
which the SPC combines with the user name and performs the hash frmction 
25 HO to produce the first hash of die hash in algorithm shown in Figure 4. This 

hash of the user name and password is then encrypted with the session key 
generated during authentication and sent to the SPS. The SPS decrypts the 
hash and stores it in the SPS database 8. 
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Notably^ the new password is sent in hashed form and encrypted, to 
avoid the password being read at any stage during the password change 
procedure, step 42. 

The SPS then initiates a challenge/response procedure as described 
5 above, to re-audienticate die user, step 44. If an incorrect response is received 

by the SPS, the user is logged off, step 40, and the log on history of the user 
is updated. If the correct response is received, the log on status of d>e user 
is updated in the CMS, step 46, and the connection is closed, step 30. 

With terminals of the type Tl, which will allow a connection to be 
10 opened by the CMS over die Internet, a procedure as shown in Figure 5 is 

followed by the CMS after log on. 

When a user is first logged on, or when the CMS receives a log on 
update from the SPS, die CMS initiates a timer for diat user, which operates 
to ensure tiiat users are logged off after a period of inactivity, for example 5 
IS minutes. After the timer is initiated in step 48, if the timer times out, or when 

a high value service is requested from one of the application servers APS, the 
CMS opens a connection with the CMSC, step SO. The CMSC then initiates 
the challenge/response procedure using a new randomly-generated challenge, 
step S2. The response by the CMSC is computed by die SPC« 
20 If the xesix>nse returned by the CMSC matches diat computed by the 

server, then the CMS resets die user's timer, step S4, and closes the 
connection, step S6. The encryption key generated during the calculation of 
this response is discarded, so diat the session key generated during Uie initial 
authentication procedure, or the key generated during die password change 
2S procedure, is maintained for encryption purposes. 

If the response returned by the CMSC does not match diat computed 
by die server, then die user is logged off the CMS, step 58, die log on history 
of die user is updated, and die connection is closed, step 60. 
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The CMS is also able to send commands to users at terminals of the 
class Tl. To send a command, the CMS opens a connection with the CMSC, 
step 62, and performs a command sequence, step 64, before closing the 
connection, step 66, Various command sequences are provided for. The 

5 CMS may request a file from the SPC, by sending a "send file" command, 

which includes the name of the file to be sent. The SPC then sends the 
original size of the file, the total number of bytes that will be sent, and the 
encrypted contents of the file to the CMS. The CMS may also download files 
to the CMSC, with a "receive file" command which includes the file name to 

10 be sent. The CMSC displays a file browser to the user to allow the 

destination of the file to be chosen and to change the name of the file. The 
CMS then sends the content of the file in encrypted form. 

The CMS may also retrieve a list of files and directories in a given 
directory from the CMSC. Once the CMS has opened a connection, a "get 

IS directory" command is sent, including the name of the directory to be 

letrieved. The CMSC then sends a list of files and sub-diiectoiies in that 
directory. 

The CMS may also send a message to the SPC containing the inidai 
password of a new user. When a new user account is created in the SPS, the 

20 CMS opens a connection and sends the new password, which is randomly 

generated, in encrypted form to maintain the security of the system. 

Where no connection opening path exists from the CMS to the CMSC, 
as in the case of the class of terminals T2, a procedure as illustrated in Figure 
6 is followed to update the log on status of the usen in die list of logged on 

25 users in the CMS. When a user is initially logged on in the CMS, or when 

a log on update is received from the SPS, the CMSC initiates a timer allocated 
to the user, step 68. In order to maintain the log on status of its user, the 
CMSC periodically contacts the CMS, with a frequency somewhat greater than 
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the frequency of time-out of the user's timer, to perform the updating. The 
CMS then accepts the connection opening request from the CMSC, step 70, 
and initiates a challenge/response procedure similar to that used in the initial 
authentication process, step 72. If the correct response is received, the user's 

S timer is reset, step 74, the connection is closed, step 76, and the encryption 

generated during the challenge/response procedure is discarded. 

If however no challenge request is received from die CMSC within the 
time-out period, the CMS acts to log off the user, st^ 78, and updates the 
user's log on history. Once logged off, the user can no longer access any of 

10 the application servers AS of the system. 

The authentication scheme described in relation to users at terminals Tl 
or T2 described above involves identification of a user, after initial 
authentication, by the IP address of the terminal at which the user is logged 
on. Because the CMS performs periodic re-authentication of the user, if is 

IS difficult for a third party to impersonate the user by IP address spoofing. 

Namely, even if a third party were to spoof the IP address of the user, the 
third party would only have access to the real user's resources for the time 
provided by the user's timer in the CMS. Once the timer has expired, the 
third party forming the IP spoofing would not be able to re-authenticate, 

20 without access to the user's password. Since the user's password is only ever 

sent across the Internet when a password change occurs, and even then in 
encrypted form, a third party has no means of finding out the password of an 
authorised user. 

Since the class of terminals T3 individually have no unique IP address, 
2S a different authentication scheme is provided, as illustrated in Figure 7. A 

user at a terminal T3 logs on to the system via an application server APS. In 
the following, the application server exemplified is a WWW server, using 
HTTP to format communications with the application client APC. However, 
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it will be appreciated that a similar authentication scheme may be implemented 
in other types of network server, using different network communications 
protocols. 

The application client APC in this case is a WWW browser, such as 

5 a Netscape Navigator, or Microsoft Internet Explorer (Trade Marks) browser. 

In order to access the application server, the application client sends a request 
for a document over the Internet. In order to identify and locate a document 
in any WWW server, files are identified by a universal resource locater 
(URL). The URL is structured to identify the service protocol (which in this 

10 case is HTTP), the "domain" of the Internet server, the directory of the file 

in the Internet server, and the file name. The URL structure is as follows: 
HTTP: //domain/directory/file name. 
This authentication scheme uses the functionality of packets of 
informadon sometimes referred to as "client-side persistent information'* but 

IS morecommonly referred to as "cQokies". Cookies may be sent from a WWW 

server, embedded in a document sent on request by that server. On receiving 
a cookie, the browser automatically stores the information in the cookie, and 
automatically transmits the information in a document request whenever the 
browser is attempting to retrieve a document from a server in the same donuiin 

20 as the server from which it received the original cookie. Cookies are referred 

to as "client-side persistent information". The application client APC used in 
the present embodiment is a browser which supports cookies* such as those 
mentioned above. 

In this case, since die user has no unique IP address, the application 

25 server sends the application client APC a cookie containing an identifying tag 

for the user, referred to herein as an address token since it replaces the IP 
address as the means for identifying die user, which consists of a large random 
number. The application client APC stores the cookie and prompts the user 
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to enter their user name and password, on which the SPC performs the first 
hashing function HO illustrated in Figure 4. The implication client APC then 
returns the address token along with the hash of the user name and password, 
whereby the application server APS performs authentication of the user via the 
CMSandSPS. 

Figure 7 shows the event sequence in terms of actions taken by the 
application server APC during authentication of a user based at terminal T3. 
When the application server APS receives a document request, step 80, the 
APS checks whether the request contains an address token as a result of a 
cookie previously being sent to the application client APC. If the document 
request contains no such address token, the application server sends the APC 
a cookie containing a newly generated address token, which the APS also 
stores as an as yet invalidated address U)ken, step 82. 

In remm, the APS receives the authentication details from the APC, 
stq> 84, including the same address token, whereby the user is re-identified, 
and the hash of the user name and password. This information is passed on 
to the CMS, which polls the SPS to check whether die user name and 
password hash matches one stored in the SPS store 8 as that of an authorised 
user. 

If the hash returned by the APC is one of a valid user, and if no 
concurrency limits are exceeded on die number of users having the same user 
identification in die CMS store 10, the CMS retrieves the user's access eights 
token from the SPS store 8. If die access rights token then indicates that the 
user is allowed access to the application server to which the log on attempt is 
being directed, die CMS sends an access allowed message to die APS, and 
stores die address token of die user and die access rights token in die CMS 
store 10. On receiving the access allowed message, the application server 
sends the requested document, step 86. 
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If however the CMS, on checking the details in the SPS, determines 
that the authentication details supplied by the user are invalid, step 88, the 
APS receives an access denied message and generates a new address token and 
sends a new cookie to the application client The new address token contains 
5 a flag indicating that the user has failed already once to provide correct 

authentication details, which flag is incremented each time the user fails to 
authenticate. Once die user has foiled three times to authenticate, the APS 
sends an error message to the APC, indicating that the user will not be logged 
on, step 90. 

10 If the CMS determines from the access rights token received from the 

SPS database 8 that the user is not entitled to access the application server to 
which the access attempt is being directed, step 92, the application server 
sends an access denied message to the application client indicating that the user 
is not entitled to log on to that particular APS, step 94. 

IS Figure 8 illustrates the procedure followed by the CMS in order to 

update the ciirrent log on status of a user accessing via the terminal T3. When 
the user initially logs on, the CMS initiates the user's timer, step 96, which 
is set to log off the user after a set period of inactivity, for example S minutes. 
If during that time, the CMS receives a log on check from any of ttie 

20 application servers APS, due to a request of resources from the user, the CMS 

both confirms to the APS that the user is logged on, identifying die user by 
means of the address token sent to the terminal when the user is initially 
logged on, and resets the timer, step 98. After die period of set inactivity, the 
timer times out and the user is removed from the stored list of currently 

2S authenticated users by die CMS, step 100. As die user is logged off, die CMS 

updates the log on history of die user, for billing purposes. 

Since the functionality of sending cookies at present is such diat a 
browser will send information containing a cookie to any of the application 
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servers within the same domain as' an application server which initially 
supplied the cookie, the application servers of the present embodiment are 
preferably located in a common Internet domain. However, a similar 
functionality could be provided by servers in multiple domains, by arranging 
5 the application client such that the details in a cookie are sent to any of the 

application servers within the system, or by sending multiple cookies for 
application servers in different domains. 

Figure 9 illustrates a particular embodiment of application server, 
referred to as a secure file transfer server (SFTS), which may be used in the 

10 system of the present invention to transfer files between a first client terminal 

102 and a second client terminal 104. 

Each of the client terminals 102, 104 are of the terminal class Tl or 
T2. During log-on to the system using die described interactions between their 
respective authentication clients AC and the authentication server AS of the 

IS system, a session key is generated which is used for encryption and decryption 

of files which are. to be transferred between die client terminals 102, 104 and 
the security server 106. In this embodiment, the client terminals 102 and 104 
each include two application cUents, namely a file/nuul sender client (FSQ 
and a file/mail receiver client (FRC). Encryption/decryption of files takes 

20 place in a security layer (SL) using the session key stored in the authentication 

client AC after log-on of the user. 

The SFTS interrogates die authentication server AS whenever service 
is requested from eitiier of die client terminals 102, 104, to check that the user 
at the terminal is currentiy logged on to the system, and to retrieve the session 

25 key from the autiienticatipn server. 

As shown in Figure 9, when a file is uploaded firom tiie first client 
terminal 102 to the SFTS, the file is transferred to a pre-processor 108 which 
sends an acknowledgement or error message to die sender out box 110 
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depending on the outcome of the pre-processing. After successful pre- 
processing, the file is transferred to an in-bound queue 112 of a file transfer 
processing system (FTPS) on the server side. 

When a file is processed by the FTPS, the type of file transfer is 
determined, and using file uansfer parameters stored in a file transfer 
parameter store 106, the FTPS may perform a file conversion, using one of 
the plug-in conversion modules 116, before the file is passed on to an out- 
bound queue 120 by (he FTPS. When the file leaves the out-bound queue 120, 
the file is passed to a post-processor 122, which sends an acknowledgemmt 
or an error message to the similar outbox 1 10, depending on the outcome of 
post-processing. If post-processing is successful, the file is sent to the 
recipient outbox 124, where it is retrievable by the PRC of tfie second client 
terminal 104. When the second client terminal 104 connects to the SETS to 
retrieve the file, an acknowledgement or an error message is sent to the sender 
out4)ox, dqwnding on the results of downloading to the second client terminal 
104. The first client terminal 102 can then access its sender outbox 110 to 
ronfirm correct receipt of the file by the recipient terminal 104, on the basis 
of the acknowledgements posted to the sender out box, or to retrieve an mor 
message and to re-send the file as appropriate. 

Figure 10 illustrates procedures followed by the SFTS when contacted 
by a client terminal which is to upload and/or download files to/from the 
SFTS. 

First, the SFTS accepts the connection request, step 130, which 
contains the IP address of the client terminal requesting access. Using this IP 
address, the SFTS checks in the AS whether the user's IP address is stored in 
the list of logged-on users. If so, the SFTS retrieves the session key stored 
in the AS for that user, and confirms with the client terminal that the user has 
access to the SFTS. If not, the SFTS closes the connection, step 132. 
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Once the client terminal has received an access confirmation from the 
SFTS, the client terminal may send requests to the server as illustrated in the 
remainder of the procedure of Figure 10. 

Each user of the file transfer system is a member of at least one of a 
S number of a Closed User Groups (CUGs), whose members are identified in 

the file transfer parameter database 126. Each Closed User Group has a list 
of transfer types for its members to use to exchange files amongst each other. 
A transfer type is created by an administrator of the Closed User Group, by 
setting up various parameters for the transfer type including its name and a 
10 version number which is incremented evei7 time the transfer is updated. This 

information is stored in the file transfer parameter store 126, and is used by 
the server to provide the client terminal with a list of transfers available to the 
user, by using the command/response procedure illustrated in Figure 11. 

In order to obtain a directory of the transfer lists available, the FSC of 
15. the client terminal sends a "transfers" command in response to which die SFTS 

sends a series of lines containing the names and version numbers of the 
transfer lists available to that user, step 134, which is then stored in die client 
terminal by the FSC. Each CUG has an associated transfer list, and each list 
name provided in the transfer directory is a representative name for its 
20 associated CUG, whereby the user identifies the list required. 

When the FSC detects a list which is new, or one which has been 
updated, the FSC downloads that list from the SFTS using the "Getlist" 
command, as illustrated in Figure 12. In response, the SFTS retrieves the file 
transfer type list fiom the file transfer parameter store 126 and transmits it to 
25 the client terminal. The list received for the CUG in question is stored by the 

FSC in die client terminal 4 and later used during file transfer. 

Each transfer list includes a header indicating the list name and the 
version number, and a number of transfer types. For each transfer type, the 
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list includes a short name, a longer name, an encryption type indicator, an 
output directory name, an input directory name, an archive directory name, 
a file mask, a receipt flag, and a delay flag. 

The short name included in each transfer type is a unique short name 

S for that transfer type, which is sent during client/server file transfers to 

identify die transfer type. The longer name of each transfer type is a 
descriptive name which is displayed to the user to allow the user to identify 
and select die transfer type. 

The encryption type indicator in each transfer type has three possible 

10 settings, namely "none", "normal" or "delayed". If the indicator is "none", 

no encryption is used during upload/download of files. If the indicator is 
"normal" the files are encrypted/decrypted during upload/download from the 
SFTS by the security layer of the client terminal and by the SFTS itself. If 
the indicator is "delayed" the files are encrypted/decrypted during 

15 upload/download from the server, as is the case for "normal", and the file is 

also encrypted a second time prior to transmission with an "embargo** key, to 
be described later. 

The output directory name is a suggested directory where files for this 
particular type of transfer are to be retrieved from for sending. When 

20 selecting files for upload die FSC takes die user to diis directory, although the 

user is still able to select files from a different directory. 

The input directory name is a suggested directory where files for this 
particular type of transfer are to be stored on receipt. When downloading a 
file, the FRC places the file in diis directory unless otherwise specified by the 

25 user. 

The archive directory is a suggested directory where files of diis type 
of transfer will be moved to in die sending terminal system after a successful 
upload. Again, the user can choose a different archive directory if desired. 
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The file mask for each transfer type defines a file selection mask which 
guides the selection of files for transfer using this transfer type. If a transfier 
requires multiple file selecdon masks, multiple file mask entries are specified. 
The recdpt flag is set either at "Y" or "N". If "Y" an automatic 
S acknowledgement is required from the server when the file is pre-processed, 

delivered for download and dovmloaded by the recipient, respectively. If '•N" 
no acknowledgement is required. 

The delay flag for a transfer type may be "Y", or "N". If "Y" files of 
this type will be delayed by storing the file in the recipient outbox 124, and 
10 made available for delivery only after a date which is specified by the user. 

If "N", the files are made available in recipient outbox 124 without delay. 

Once the terminal is sent any new transfer list, the user is able to 
request a file to be uploaded to the SFTS, using the command/response 
procedure illustrated in Figure 13. The FSC inidates the transfer by sending 
IS the "sendfile" command with the name of the file to be uploaded (with any 

directory pre-fixes removed) and the identity of the intended recipient(s). The 
SFTS will generate a unique ID for this transfer which is then sent to the 
client terminal. The transfer ID is used by the server to identify a file 
throughout the transfer process and provides a means of preventing errors 
20 which would otherwise occur with duplicate file names. 

Once the transfer ID has been assigned, the FSC sends the SFTS 
headers specifying the chosen transfer type, the original size of the file (in 
bytes), the total number of bytes that will be sent (including the overhead from 
the encryption process), and an optional date which represents when a file may 
25 be released (if using embargoed encryption) or when a file should be made 

available for delivery (in the case of deferred transfers). 

When the headers have been sent, the encrypted fde data is sent to the 
server as a series of blocks having the configuration illustrated in Figure 14. 
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Each data block includes five parts, including an initialisation vector 
ISO for the decryption process, added during encryption and prior to 
transmission of the block. The block also includes a block number, 152, 
which increments with each block of data sent, and a data count 154, which 

5 is a count of the number of data bytes included in the data block, excluding 

the initialisation vector 150, block number, data count, checksum and any 
padding added during the encryption process. The next part of the data block 
is the part holding the encrypted data 156, which is padded to a multiple of 8 
bytes by the encryption function if the data block is not otherwise a multiple 

10 of 8 bytes. The final part of the data block is an encryption checksum 158, 

which is added by the encryption function and checked and removed by the 
decryption function to ensure that the data block has been received correctly 
after transmission. 

When an uploaded file is received by the SFTS, the file is generally 

15 processed by the pre-processor 108, the FTPS and the post-processor 122, and 

is sent to the outbox 124 of the intended redpieht of the file. 

Each recipient outbox keeps an updated directory of files to be 
downloaded to the recipient, which directory can be downloaded by a 
receiving client terminal PRC, step 140, by using die command/response 

20 procedure illustrated in Figure 15. If the transfer type indicates a deferred 

transfer, the file is stored invisibly in the recipient outbox and included in the 
directory only after the time and date specified in the transfer request. 

To obtain a list of files waiting on the server for the user to downloofd 
(if any), the FRC sends a "Directory" command, in response to which the 

25 SFTS sends a directory listing which contains, for each directory entry, the 

transfer ID assigned to the file when it was uploaded by the sender, the file 
transfer type, the original name of the file, the original size of the file in 
bytes, the total number of bytes that will be sent if the file is downloaded, the 
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user ID of the file sender, the date upon which the file was ddiveied to the 
user's outbox on die server, an encryption flag ("Y" if die file users 
embargoed encryption, "N*" for odier types of transfen), a date/dme upon 
which die embargo key will be released for distribution if die file is 

S embargoed, and a unique identifier for die embargo key used to encrypt the 

embargoed file, if die file is embargoed. 

Once the FRC has received a directory of die files waiting to be 
retrieved die FRC may download one of die files, step 142, using the 
command/response sequence illustrated in Figure 16. To initiate the download 

10 of a file, die FRC sends a **Getfile* command to die server widi die transfer 

ID as indicated in die directory listing of die file to be retrieved. The FRC 
dien sends die "Block" line to indicate which data blocks are to be 
downloaded. The "Block" line can indicate a single block number (eg "0"), 
a list of blocks (eg "0, 1. 2. 5") or a range of blocks (eg "0-9"). To 

IS download a file in its entirety, die FRC sends a block line widi a block 

number of zeros. The SETS then encrypts dte file using die session key held 
for the receiving client terminal, and sends die selected data blocks to die 
FRC. 

At die receiving terminal end, the security layer SL uses die session 
20 key to decrypt the file. Should die downloaded file fiul to decrypt correcdy, 

die file is retrieved from the SFTS again in its entirety. 

For added security on die server side, it is possible to re-encrypt a file 
with a locally-generated encryption key after decryption using die session key 
of die sending terminal, and to decrypt the file using die locally-generated 
25 encryption key immediately prior to processing by die FTPS. It is also dien 

possible to re-encrypt die file widi a fiirther locally-generated mcryption key 
after processing by die FTPS, and to decrypt die file using die fiirdier locally- 
generated encryption key immediately prior to re-encryption of the file using 
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the session key of the receiving tenninal. 

If a file transfer is of an embargoed type, as well as being encrypted 
with the session key of the receiving terminal, it is also encrypted by the SFTS 
using an "embargo" key prior to delivery and assigned an embargo key 
5 identifier. This means that once downloaded, the file still cannot be read as 

it remains encrypted with an encryption key derived from the embargo key 
after decryption using the session key. The file encrypted using the embargo 
key is stored along with the embargo key identifier by the FRC in the client 
terminal until such time as the embargo key is released and the file can be 
10 decrypted. 

Embargo keys are generated either automatically or manually. If 
automatically generated, the SFTS will assign a randomly generated key when 
the uploaded embargo file is processed. If manually generated, a system 
administrator will have entered embargo keys for one or more specific 
IS transfers in advance. 

The embargo key consists of a series of words or a phrase, with up lo 
40 characters. Before an embargo key is used, it is hashed using the HO 
hashing function illustrated in Fig. 4, using the embargo key twice as first and 
second inputs to the fiincdon, to produce the actual encryption key for use in 
20 the encryption/decryption process described above. 

The embargo key is delivered by E-mail or file transfer at the time and 
date specified when the embargoed file is uploaded to the SFTS. When ttie 
embargo key is sent, the E-mail message or die file transfer containing the 
embargo key includes the identifier for the embargo key, the embargo key 
2S itself, the encryption key generated from the embargo key using the HO 

fiincdon and one or more file transfer ID*s for which the embargo key may be 
used to decrypt the files. 

The embargo key may be made available to a user by other means, for 
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example by normal postal services, or by posting the embargo key onto a 
WWW site, which can be s^ccessed by users after the date and time specified 
for release of the embargo keys. 

Figure 17 illustrates a further embodiment of the present invention, in 

S the form of an E-mail server, 160, which is able to accept messages from an 

E-mail client application 161 via the Internet, to store the message in a delayed 
E-mail store 162 until a prescribed date and time, and then to deliver the 
message to the mailbox 164 of the recipient at the prescribed date and time. 
After the prescribed date and time, the recipient mail client 166 is able to 

10 retrieve the message for viewing by the user. 

The delayed E-mail message is essentially similar to a conventionally- 
known E-mail message, and contains extra fields in the message header. 
These extra fields include a "delayed" field, which marks the message as a 
"delayed** E-mail, and specifies the date and time when the E-mail should be 

IS delivered to the mailbox of the recipient. The date and time are indicated 

using the day of the month, the montii of the year, the year, the hour of the 
day and the minute past the hour of the intended ddivery time. The extra 
fields also include a "confirm delivery" field which indicates whetiier the 
sender requires an acknowledgement when the delayed message is sent to the 

20 recipient. If no acknowledgement is required, the "confirm delivery' fidd 

need not be supplied, or is set to negative. 

The delayed E-mail server 160 may thus be used to transmit a message 
from the SETS containing an embargo key, which indicates the date and time 
at which the embargo key should be released to a file recipient. The mail 

25 server 160 then delivers die embargo key at the required date and time without 

further reference to the SETS. If an acknowledgement is required by die 
SETS, the server 160 sends an acknowledgement to the SETS confirming 
delivery, or an error message if the message could not be dorrectiy 
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transihitted. 

It will be appreciated that various modifications and variations are 
possible in relation to the above-described embodiments without departing 
from the spirit or scope of the present invention. 
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1. A method of authenticating users for access via remote terminals to a 
plurality of application servers, said method comprising the steps of: 

storing authentication details of authorised users; 
S performing remote authentication of users with reference to said stored 

authentication details; 

storing data identifying users which are currently authenticated; and 
allowing said plurality of application servers to access said data 
identifying currently authenticated users to check an authentication status of a 
10 user. 

2. A method according to claim 1, wherein said authentication step 
comprises issuing a challenge to a user terminal, receiving a response to said 
challenge, and verifying said response. 

31 A method according to claim 2, wherein said authentication step further 
IS comprises generating a random string for use as said challenge and computing 

an expected response for use during verification. 

4. A method according to claim 3, wherein said expected response is 
computed using an authenticator derived from a jpassword and stored with said 
authentication details. 

20 S. A method according to claim 4, wherein said authenticator is a hash 

produced by a one-way hashing function acting on a user password. 

6. A meti\od according to claim 4 or S, further comprising the step of 
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allowing a user to change the authenticator stored with said identification 
details, by receiving a new password as a hash produced by a one-way hashing 
function from said user terminal. 

7. A method according to any preceding claim, further comprising 
S producing an encryption key during said remote authentication step. 

8. A method according to claim 7, wherein said encryption key is stored 
as a shared secret key on said user terminal and in said data identifying users 
which are currently authenticated. 

9. A method according to any preceding claim, further comprising the 
10 step of periodically performing re-authentication of a user in order to update 

said data identifying users which are currently authenticated. 

10. A method according to claim 9, wherein said re-authentication step 
comprises issuing a challenge to a user terminal, receiving a response to said 
challenge, and verifying said response. 

IS 11. A method according to claim 9 or 10, wherein said re-authentication 

step is performed in response to a time-out associated with said data 
identifying cunendy authenticated users. 

12. A method according to claim 9 or 10, wherein said re-authentication 
step is performed in response to access by one of said application servers to 

20 said data identifying currendy audtenticated usen. 

13. A method according to claim 9 or 10, wherein said re-authentication 
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step is performed in response to a request by a user terminal. 

14. A method according to any preceding claim, wherein said remote 
authentication is performed over the Internet. 

15. A method according to claim 14, wherein said users arc identified by 
5 means of the IP address of their user terminals by said application servers. 

16. A method according to claim 1 or 2, wherein said authentication step 
comprises issuing an identification token to a user terminal. 

17. A method according to claim 16, wherein said authentication step 
comprises receiving said identification token from said user terminal with an 

10 authenticator of a user at said user terminal. 

18. A method according to claim 17, wherein said authenticator comprises 
a hash produced by a one-way hashing function acting on a user password. 

19. A method according to claim 17 or 18, wherein said authentication step 
comprises issuing a new identification to said user terminal if said 

IS authenticator is invalid. 

20. A method according to claim 19, wherein said new identification token 
comprises data indicating the number of times an invalid authenticator has 
been received fh>m said user terminal. 

21. A method according to claim 20, wherein said method comprises 
20 refusing access by said user terminal to said application servers if said 
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identification token indicates that a predetermined number of invalid 
authenticators have been received from said user terminal. 

22. A method according to any preceding claim, wherein said data 
identifying currently authenticated users is stored on a storage means which 

5 said application servers are each able to access. 

23. A method according to any preceding claim, wherein said 
authentication details include data identifying the rights of access of individual 
users to one or more of said application servers. 

24. A method according to claim 23, wherein some users have access rights 
10 to only some of said application servers. 

25. A method according to any preceding claim, further comprising storing 
data identifying the periods for which users have held a currently^authenticated 
status. 

26. A method according to any preceding claim, further comprising 
15 analysing said data identifying users which are currently authenticated to 

ensure only a predetermined concurrency of authenticated users is present 
therein. 

27. Apparatus for performing the steps of any preceding claim. 

28. Apparatus according to claim 27, wherein said authentication stq> is 
20 performed by an authentication server. 
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29. A method of transferring a file between a user at a first client terminal 
and a user at a second client terminal over the Internet, said method 
comprising the steps of: 

establishing a first session key by communicating with said first client 
5 terminal over the Internet; 

receiving the file encrypted with the first session key from the first 
client terminal over the Internet; 

decrypting the file using the first session key; 

establishing a second session key by communicating with said second 
10 client terminal over the Internet; 

encrypting the file using the second session key; and 

transmitting the file encrypted with the second session key to the 
second client terminal. 

30. A method according to claim 29, comprising storing said file after 
15 recdpt from said second client terminal until requested by said second client 

terminal. 

31. A method according to claim 30, comprising storing said file after 
transmission to said second client terminal until a command is received from 
said second terminal to delete said file. 

20 32. A method according to claim 30 or 31,j::omprising transmitting a list 

of stored files to said second client terminal, and transmitting one of said 
stored files in response to a selection from said list by said second client 
terminal. 



33. .A method according to claim 30, 31 or 32, comprising encrypting said 
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file with a third encryption key during said storage, and decrypting said file 
with said third encryption key before transmission. 

34. A method according to any of claims 29 to 33, comprising transmitting 
an acknowledgement to said first client terminal after successful transmission 

S of said file to said second client terminal. 

35. A method according to any of claims 29 to 34, wherein said first and 
second session keys are generated by issuing a different random string tt> said 
first and second client terminals, respectively. 

36. A method according to any of claims 29 to 3S, comprising storing said 
10 file for a predetermined period before said second client terminal is able to 

access said file. 

37. A method according to any of claims 29 to 35, comprising encrypting 
said file with a fourth encryption key before transmitting said file to said 
second client terminal, and subsequently releasing said fourth encryption to 

IS said second client terminal to allow decryption of said file only after a 

predetermined period. 

38. A method according to claim 36 or 37, wherein said predetermined 
period is specified in a message received from said first client terminal. 

39. A method according to any of claims 29 to 38, further comprising 
20 storing file transfer parameters defining a plurality of different types of file 

transfer and transmitting a list of different transfer types to said first client 
terminal. 
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40. A method according to claim 39, further comprising receiving data 
identifying one of said file transfer types from said first client terminal for 
processing said file when received from said first client terminal. 

41. Apparatus for performing the steps of any of claims 29 to 40. 

S 42. A method of transferring a file from a first client terminal to a second 

client terminal, said method comprising the steps of: 

holding file transfer parameters for a plurality of different file transfer 

types; 

transmitting data relating to at least one of said different file transfer 
10 types to said first and/or second client terminal; and 

conducting a file transfer between said first and second client terminals 
in accordance with file transfer paiameters stored for a selected file transfer 
type. 

43. A method according to claim 42, comprising: 
IS receiving said file from said first client terminal; 

receiving data identifying a selected file transfer type from said first 
client terminal; and 

transmitting said file to said second client terminal in accordance with 
the file transfer parameters stored for said selected transfer type. 

20 44. A method according to claim 42 or 43, wherein said holding step 

comprises holding a list of transfer types associated with each of a plurality of 
user groups, and transmitting a list to. said first client terminal when a user at 
said first client terminal is a member of the associated user group. 
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45. A method according to claim 42, 43 or 44, wherein said file transfer 
parameters include a file encryption parameter, and wherein said file transfer 
step comprises encrypting said file during said transfer in accordance with a 
file encryption parameter stored for the selected file transfer type. 

5 46. A method according to claim 45, wherein said file encryption 

parameter indicates an embargo period for said encrypted file« and said method 
comprises transmitting an encryption key to said second client terminal to 
allow said file to be decrypted after said embargo period has expired. 

47. A method according to any of claims 42 to 46, wherein said file 
10 transfer parameters include a suggested storage directory for a file. 

48. A method according to any of claims 42 to 47, wherein said file 
transfer parameten include a file acknowledgement parameter, and said file 
transfer step comprises transmitting an acknowledgement to said first client 
terminal in accordance with a file acknowledgement parameter stored for the 

15 selected file uransfer type. 

49. A method according to any of claims 42 to 48, wherein said file 
transfer parameters include a transmission delay parameter, and said file 
transfer step comprises transmitting said file to said second client terminal only 
after expiry of a delay period in accordance with a transmission delay 

20 parameter stored for said selected file transfer type. 

50. Apparatus for performing the steps of any of claims 42 to 48. 

51. An application server for transferring data from a first client terminal 
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to a second client terminal, said application server comprising means for 
receiving said data from said first client terminal, means for receiving a delay 
period indicator for said data from said first client terminal, and means for 
transmitting said data to said second client terminal such that said data can 
S only be read by a user at said second client terminal after expiry of said delay 

period. 

52. An application server according to claim 51, wherein said application 
server comprises means for encrypting said data with an encryption key prior 
to transmission to said second client terminal, and means for forwarding said 

10 encryption key such that said second client terminal is able to access said 

encryption key only after expiry of said delay period. 

53. An application server according to claim 52, wherein said application 
server comprises means for transmitting said encryption key to said second 
dient terminal after expiry of said delay period. 

15 54. An application server according to claim 51, comprising means for 

storing said data for the duration of said delay period prior to transmission of 
said data to said second client terminal. 

55. An E-mail server according to claim 54, wherein said data comprises 
an E-mail message. 




SUBSTrniTE SHEET (RULE 26) 



WO99/D09S8 



PCT/GB97/01755 



2/11 





o 

CCLU 
OCD 




ENGE/ 
ONSE 


1 


PASS\ 
CHA 


— ► 


CHALL 
RESP 









SUBSTITUTE SHEET (RULE 26) 



wo 99/00958 



FCT/GB97/017SS 



3/11 




SUBS'l l'l'U'l'K SHEET (RULE 26) 



wo 99/00958 



PCT/GB97/D175S 



4/11 



USERNAME 
PASSWORD 



HO 




HI 







?EN( 



ENCRYPT/DECRYPT 



Fig.4. 

-CHALLENGE 




RESPONSE 

►FROM CLIENT TO SERVER 
FROM SERVER TO CLIENT 



48 



( START ) 



^ INITIATE 
TIMER 




SEND 

C COMMAND 

9 



OPEN CONNECTION | 




1 






COMMAND 
SEQUENCE 










■CLOSE CONNECTIONI 



Fig.5. 



^50 

OPEN CONNECTION | 



CHALLENGE/ 
RESPONSE 



52 




LOGOFF 
USER 



I 



54 



RESET 

TIMER 



I 



CLOSE connection! |close connection! 



SUBSTITUTE SHEET (RULE 2S) 



WO99/009S8 



PCT/GB97/0175S 



5/11 




SUBSirrUTE sheet (rule 26) 



WO99/009S8 



PCT/GB97/017SS 



6^11 



80 



( START ) 

RECEIVE DOC 
REQUEST 



Fig.7. 



SEND 
REQUESTED 
DOC 



731: 

( END ) 




82 



SEND 
ADDRESS 
TOKEN 



I 



RECEIVE 
AUTHENTICATION 
DETAILS 




NO ACCESS 
RIGHT 



94 



I 



SEND ACCESS 
DENIED 
MESSAGE 



( END ) 



88 



INVAUD 
DETAILS 




SEND ERROR 
MESSAGE ^ 



( END ) 



SUBSTITUTE SHEET (RULE 26) 



WO9MI09Si8 



PCT/GB97/017S5 



7/11 



Q 




suBsnrruTE sheet (rule 26) 



wo 99/00958 



PCT/GB97/01755 



( STARTJ 

^ 1 130 

ACCEPT CONNECTION 



Fig.10. 




132 



SVBS'lTI'U'l'E SHEET (RULE 26) 



WO99/009S8 



PCryGB97/017SS 



9/11 



Fig.11. 



Qient 


Transfers: ^ 


Server 






^ </fef name>:<vefsion>: 


m • 
• • 

^ End 





Fig. 12. 



Client 


GetUst: </*sf name> ^ 


Server 






<file data> 


^ 

• • 

• • 

End 





SUBSnrVTE SHDEET (rule 26) 



WO99/009S8 



PCT/GB97/0175S 



10/11 



Fig. 13. 



Client 



Sendfile: <filename> 



Id: < transfer ID> 



Type: < transfer type> 



Date: <date>^ 



<encrypted file data> 



Server 



Optional date field, 
required for 
embargoed / 
delayed transfers 



Byte Offset 0 
8 

12 
16 



16-f Count 



Fig. 14. 



Encryption IV 
(8-4)ytes) 



Block Number 
(4-bytes) 



Data Count 
(4-bytes) 



Data 



Encryption Checlcsum 
(8-bytes) 



150 
152 
154 



6 



158 



SUBSTTTUTE SHEET (RULE 26) 



wo 99/00958 



PCT/GB97/017SS 



11/11 



Fig. 15. 



Client 


Directory: ^ 


Server 






^ <of/r entiy> 


• • 

• • 

\i\n 


^ 



Fig. 16. 



aient 


Getfile: <^ _ 


Server 






Block: <a[,br> ^ 


^ <efwrypled file data> 


• • 



Fig.17. 

CLIENT NETWORK SERVER 




SUBSTITUTE SHEET (RUUE 26) 



INTERNATIONAL SEARCH RJBPORT 



Inlam lal AppUoatkmNo 

PCT/6B 97/01755 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 He4L29/06 GQ6Fl/ee H04L12/58 



Aooordbg to tntimatouJ Ptdmt Oto— iHoartcm 0PO) or to both n^lkmai otowWoation nd tPO 



B. RELOS SEARCHa> 



MWmuin dooiMiMntition Mantwd 

IPC 6 He4L Ge6F 



(Blonfficalbn •yitam fottowMl by ciasaifiaaiion ftynteto) 



DoounMtiMkMiiMfdMd other Ihaninnlnijm feittwfMdSMarahftd 



ElMliDfilodaUbiBcopmuiBddiifinglh* <nt>mrtbnal wareh (iwwwol riati h— Md, «fhM«pnwlioal,MMDhtBfTmiiM«0 



C. DOGUMENIB CONSIOERED TO BE RELEVANT 



Cfltogofy* Ctation of doounwnt w(tti bdnction, wtt«m appraprk^ 



fWlmidlodlflJmNo. 



US 5 373 559 A (KAUFMAN CHARLES U 
13 December 1994 

see column 1» line 8-34 



ET AL) 



see column 2» line 61 - column 3» line .19 

see colian 7» line 39 - column 8» line 39 

see column 10, line 53-58 

see column 11» line 58 - column 13, line 

17 



1-5,7.8. 

16-18, 

22.23 

6.9.10. 

13.24 



iMiMinlh* ooiiiiwMiihiiiotboKC. 



m 



p#iid toiHy I 



*A* rtii 111 !■■ 1 ■<< it Bhi Imm lii I • n I ■ 1 il I a * i M ^ — t-t, l_ - » 

-E* MritordoeimwfdfauliMMMwdimorallifttw MMnrfkMurf 



^* dMMitfWNvl whioli nwy throw d o ti h ti on ptiarlty otafan^i) oc 
whloh to oM to MybtiU) Ihtt ptiiihMdkm da«* of 



liter doeyriMmk fMdiiMNid iAir« 
orprtodtyiMBandfiollnoofillalwIhth* ippto tl onfaui 

■ * , ill til ii**- - ' - * - — tfc ■ ■ ■! I II li I li jii 1 n 
BiWw ■> iifWf wwi w pnwB^wo woiy wiiMnynp BIO 



orottwf ifi«otofrMBon<M apootftod) 
*0^ doounwflt n^MTwiQ to mi oral dlMtoouM« uB#t OMhbMon or 



r aaoHiTiMii piffMonoa pnor n oiHfnflManM MRiQ OHB IM 
totor ItiMi Hm pftotity di 



*X* d u ou m »w t olpaft>qid<r r rtow M ioa:th»ciiimod hvntto w 
OMiiolb#oamldMwd niiMioroMinolb#oonsldMid Id 
Invokfo Mt bwwiftfcM stop when Iht dMUfiwnt ii talvn aIbim 

*Y* domfinfit of pwihnil>f rriiYBnw'tht trtnlnwtl InvwitkNi 
owwwf bo oonsldMWd Id InvD^M Ml kivMllM liipwhMillw 
dDOMmoid to oofMbbwd vHtti oiw or moio olhor MioHdooii' 
mtnto. tinih rnitnt^fciiilontiotoQ obwtotja to t poroofiMltod 
tottioat 

*A* dooumonlmoinboroflhooomopitoftltamiy 



Ooto of Iho MbMl eomfitotton of Iho totomitioMi ooarah 



18 Hay 1998 



Oiio of nwiing of Iho 



0 3. oa 98 



Namo «fid mottna oddTM of tho ISA 

EuropMn PiADm cmeo, P.B. SB18 Potenttaan 2 
NL-aOOHVR«MV<p( 

T«i («91-7D) 340-2040, Tx. 31 6S1 opo nl, . 
Fuc (491-70) 940-2016 

Foim PCTm/210 (MoeiMlahortl (Mr IM) 



Authorizod ofHeor 



Dupuis. H 



page 1 of 3 



INTERNATIONAL SEAKCH REPORT 



hilam. <MlApplle«HonND 

PCT/GB 97/G1755 



C^CcntbMiattan) OOCUIKMTS CONSIDEREO TO BE RELEVANT 



IMwMltoeiainiNa. 



STAINOV R: "DATENSICHERHEIT IN INTERNET: 
PRINZIPIEN. MOEGLICHKEITEN UNO GRENZEN" 
NTZ NACHRICHTENTECHNISCHE ZEITSCHRIFT. 
vol. 49, no. 8, 1 January 1996, 
pages 32-34. 36 - 38. 40. XP000623476 
see page 36. middle colunm. line 24 - 
right-hand colunn. line 16 
see page 37. right-hand column, line 18 - 
page 38. left-hand column, line 34; figure 
4 

EP e 715 247 A (XEROX CORP) 5 June 1996 

see page 2. column 1-14 

see column 3. line 52 - column 4, line 20 

see column 7. line 40-53 

see page 8; table 2 

see page 11, line 15 - page 12. line 45 

see page 15, column 39 - page 17, line 26 

see page 19, line 55-58 

see page 21. line 2-5 

see page 23, line 41 - page 24, line 1 

GB 2 047 506 A (ATALLA TECHNOVATIONS) 26 

November 1980 

see page 1, line 73-104 

see page 3, line 117 - page 7, column 28 

US 5 642 420 A (KURODA YASUTSUGU ET AL) 
24 June 1997 

see column 4. line 56 - column 7. line 27 
see column 9, line 17-23 

US 5 475 757 A (KELLY JOSEPH P) 12 
December 1995 
see abstract 

see column 5. line 21-55 

see column 9. line 45 - column 10, line 49 

US 5 548 646 A (AZIZ ASHAR ET AL) 20 
August 1996 

see column 3. line 20-29 

see column 3. line 65 - column 6. line 11; 

table 

see column 12. line 3 - column 13, line 37 

■OS/2 OFFICE: DELAYED DELIVERY FOR NAIL 
I TENS' 

IBN TECHNICAL DISCLOSURE BULLETIN, 
vol. 34, no. 9, 1 February 1992. 
pages 381-382. XP000301917 
see the whole document 



-/-- 



1.2.7. 
14.22. 
27,28 



8.15. 
23-25 
4,5 



29-36. 

38.51.54 

37 



29.30. 
34.35.41 



29.35.41 
55 

29.35.41 



42 

44.45,50 

51,54 

55 



FamPCmV»0(i 



page 2 of 3 



INTERNATIQNAI. SEARCH REPORT 



lfittm& •fli Appllcsllon Ho 

PCT/6B 97/91755 



(MContjnuaion) OOCUHENTS CONaOENEO TO BE HEtEVANT 



Cftstion cf dooufnMi^ writti fcwlifKtion«wtwPB flpprapiutoa of tlw nisvsnl pMMO#s 



MwMltBaUmNo. 



US 5 319 705 A (HALTER BERNARD J ET AL) 7 
June 1994 

see column 5, line 28 - column 6, line 16 

EP 0 695 985 A (MICROSOFT CORP) 7 February 
1996 

see page 2, right-hand column, line 18-38 

see column 2, line 26-47 

see column 3, line 15-55 

see column 6, line 8 - coluiim 8. line 40; 

figure 3 

see column 9, line 53-57 

EP G 693 836 A (SUN MICROSYSTEHS INC) 24 
January 1996 

see column 17. line 49 - column 18, line 
11 

JOHNSON J T: 'SIGN ON AND BE SAFE IBM'S 

NETWORK SECURITY PROGRAM (NETSP)* 

DATA COMMUNICATIONS. 

vol. 24* no. 1, 1 January 1995, 

page 122, 124 XPee048e828 

see page 122, middle colum, line 27 - 

page 124, middle column, line 4 

'METHOD OF AUTHENTICATED PASSMORD OR 
PASSPHRASE CHANGING" 
IBM TECHNICAL DISCLOSURE BULLETIN, 
vol. 36. no. 11, 1 November 1993, 
pages 285-289, XP90G424864 
see page 287 

US 5 497 421 A (KAUFMAN CHARLES W ET AL) 
5 March 1996 

see column 2, line 65 - column 3, line 10 
see column 4, line 15 - column 6, line 50 

PR 2 741 465 A (BULL SA) 23 May 1997 
see page 1, line 4-5 



see page 1. line 34 - page 2. line 12 
see page 3. line 3-37 
see page 6. line 1 - page 7, line 9 
see page 11. line 35 - page 12. line 8 



37 

52,53 

8,23-25 

1 



15 



24 



1-5,20, 
21 



9,10,13 
1.2.4,5, 
7,8,14, 
27 



FMni POTASMnO leonkialmi el MODiri ,«im4 (Mr IMBI 



page 3 of 3 



INTERNATIONAL SEARCH REPORT 



lnte...alional opfaioation No. 

PCt/6B 97/01755 



Box I Observatk>n« wh«r« certain dalmt wn found unMarctiaMo (Continuation of ttom 1 of first shoot) 



This International Saoroh Report has not been estatilBhed in respect of certain ctatms under Article 17(2Xa) for the foflowing reasons: 

1. n aaimsNos.: 

t)eeaLne ttiey relate to sul3fed rnatter not requited to t)e searched liy this Ati^^ 



2. ri ClfliinsNos.: 

bscsuss they rslata to parts of ttielrileffnatbnaiApplioatkm that do not comply wfth the pm 
an anient ttial no meanbigfiil MemStionSI Seaioh oan be carded out, apedfioally: 



3. I I CtaimsNoe.: 

booaina they are dependent datma and are not (Called in accordance with tlie second and third sentences of Rute 6.4(a). 



Box II Obaorvatlons whoro unity of invontioo Is lacking (Continuotion of ttom 2 of fint shoot) 



TN^s IntonMlional Searahinfl Authofily found tnuRiple imfsntions in IMs sSsmflfionsI appHostion, as foSosrs: 

see additional sheet 



t. [Tl As aymquiredaddWonal search fees wars tiinslyps^ 
seaiohafale claims. 

2. n As dlssarohafaledanwoouU be soaiched without effort [ustilyi^ 
— ' offanyoddUonalllBe. 



3. I I As only some of thsisc|uirsdaddlional search leeevvervtifnelyp^ 
■ — I oovafi only Ihcee claims lor wNch lees were psid,speeificslyclai 



4. I I NorsquirededdKnnaJaearohlees wers timely paki by ttw applicant. Corwequ^ 
reslriolad to the invention first riMHiioned in the dalma; i is covered by claims Nos.: 



Rsmatic on Protest | [ 'Hie additional searoh foes were apoompanied tiy the applicant's protest, 

[ X| ^fo protest aooompariied the payment of aclditfona} search fees. 

Fomi PCT/ISAyziO (oontinuStion of first sheet (1)) (July 1992) 



InkemattonalAppfioafionNo. PCT/GB 97/01755 
FURTHER INFORMATION CONTiNUED FROM PGT/I8A/ 218 ' 

1. Claiins: 1-28 

Method and apparatus for authenticating users. 

2. Claims: 29-41 

Method and apparatus for transferring a file via a server 
using two encryption keys. 

3. Claims: 42-50 

Method and apparatus for transferring a file between two 
terminals using a transfer type transmitted by a server. 

4. Claims: 51-55 

Method and apparatus for transferring data via a server 
using a delay indicator specified by the sender. 



INTERNAHQHAL SEARCH lUEPORT 

InforaMMon on patent tanilljf niMniMfs 



Inton. uonil AppHoiUonNo 

PCT/GB 97/01755 



Patent dooument 
cited in raoR^i report 


Pubination 
date 


Patent imly 
niainbaf(a) 


Pulilioation 
daAe 


us 5373559 


A 


13-12-94 


US 


5491752 A 


13-02-96 


EP 0715247 


A 


85-06-96 


JP 


8263438 A 


11-18-96 



GB 2647506 A 



26-11-80 



US 


4268715 


A 


19-05-81 


us 


4283599 


A 


11-08-81 


us 


4281215 


A 


28-07-81 


CA 


1149484 


A 


85-07-83 


CA 


1159124 


A 


20-12-83 


CA 


1159920 


A 


03-01-84 


CH 


646558 


A 


30-11-84 


OE 


2916454 


A 


15-11-79 


FR 


2425114 


A 


30-11-79 


GB 


2020513 


A.B 


14-11-79 


GB 


2099195 


A.B 


01-12-82 


JP 54148402 


A 


20-11-79 


US 


4315101 


A 


09-02-82 


JP 62283742 


A 


69-12-87 



US 5642420 


A 


24-06-97 


JP 


7245605 A 


19-09-95 








6B 


2287160 A 


06-09-95 


US 5475757 


A 


12-12-95 


EP 


0687087 A 


13-12-95 








JP 


8023330 A 


23-01-96 


US 5548646 


A 


20-08-96 


EP 


0702477 A 


20-03-96 








JP 


9027804 A 


28-01-97 


US 5319705 


A 


07-06-94 


JP 


7093148 A 


07-04-95 


EP 0695985 


A 


07-02-96 


JP 


8106437 A 


23-04-96 


EP 0693836 


A 


24-01-96 


US 


5588060 A 


24-12-96 








US 


5416842 A 


16-05-95 








JP 


8008895 A 


12-01-96 








US 


5668877 A 


16-09-97 








US 


5633933 A 


27-05-97 



US 5497421 A 65-03-96 US 5418854 A 23-05-95 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 

■ ■ ■ ■ ■ 111 I > - » * Ja^MHig m 

InlOniMRMIfl on PSOTII Mmlmf m 



Palentdooumant 
ottad in satroh roport 



Publbation 



jnatAppDoallohNo 

PCT/GB 97/01755 



PubliMtfiBn 



FR 2741465 A 



23-85-97 



CA 
EP 



2196690 A 
0774767 A 



21-65-97 
21-65-97 



page 2 of 2 



